Business Analyst Community & Resources | Modern Analyst

How can business analysts mitigate resistance to paradigm-shifting ideas?

Adrian M. — Mon, 10 Nov 2025 01:21:00 GMT

Business analysts can mitigate resistance to paradigm shifts by addressing both the emotional and rational sides of change.

Practical approaches:

Communicate early and often: Transparency reduces uncertainty.

Link benefits to stakeholder goals: Show “what’s in it for me.”

Pilot in small steps: Demonstrate success on a manageable scale.

Use data: Support proposals with clear evidence of improvement.

Resistance usually stems from fear of loss—of control, competence, or stability. Analysts who empathize with that fear and respond with clarity build credibility.

By treating resistance as feedback rather than opposition, BAs turn skepticism into momentum.

In what types of projects are paradigm shifts most likely to occur?

Adrian M. — Mon, 10 Nov 2025 01:19:00 GMT

Paradigm shifts in business analysis most often occur in projects where foundational change is required—typically during digital transformation, system modernization, or major process reengineering.

High-likelihood project types:

Greenfield projects: Freedom to define processes from scratch.

Reengineering initiatives: Legacy systems replaced with modern architectures.

Organizational restructures: New business models or product lines emerge.

Maintenance projects, by contrast, tend to favor incremental improvement. Recognizing the project context helps analysts adjust their mindset—innovative for new builds, conservative for sustainment.

Understanding where paradigm shifts are most likely and most valuable enables analysts to propose bold ideas at the right time.

What communication strategies can business analysts use to help stakeholders accept a paradigm shift?

Adrian M. — Mon, 10 Nov 2025 01:17:00 GMT

Business analysts can help stakeholders accept a paradigm shift by combining clear communication, evidence, and empathy. Paradigm shifts challenge comfort zones, so persuasion must be structured and inclusive.

Effective strategies include:

Show the pain: Use metrics and visuals to highlight current inefficiencies.

Tell a story: Describe how the new paradigm improves customer or employee experience.

Start small: Pilot the idea on a manageable scale to build confidence.

Involve stakeholders early: Co-creation reduces fear and resistance.

Analysts who communicate paradigm shifts as opportunities rather than disruptions gain trust and momentum.

The key is to shift the conversation from “what we’ll lose” to “what we’ll gain.”

How can business analysts differentiate between a true paradigm shift and scope creep?

Adrian M. — Mon, 10 Nov 2025 01:15:00 GMT

A true paradigm shift in business analysis changes how a problem is solved, while scope creep simply adds more to the existing solution. Distinguishing the two is critical for managing expectations and resources.

Key distinctions:

Paradigm Shift: Reframes the problem; introduces a new model or architecture.

Scope Creep: Expands requirements within the same paradigm without changing the core approach.

Example: Replacing manual approvals with AI-based decisioning is a paradigm shift; adding another approval step is scope creep.

Analysts can guard against confusion by documenting the rationale and value of each proposed change. If the change transforms outcomes rather than adds features, it’s likely a true paradigm shift deserving strategic consideration.

What analysis techniques help business analysts challenge entrenched business rules or assumptions?

Adrian M. — Mon, 10 Nov 2025 01:13:00 GMT

Analysis techniques that help business analysts challenge entrenched rules include structured inquiry methods that expose outdated or unnecessary constraints.

Common approaches:

Business Rules Analysis: Identifies rules that no longer reflect current policy or customer needs.

Impact Mapping: Tests whether existing rules contribute to desired outcomes.

Scenario and “What-If” Analysis: Reveals where current assumptions fail under future conditions.

Root Cause Analysis: Differentiates between symptomatic fixes and systemic change.

Challenging entrenched rules requires tact as well as logic. The analyst’s role is not to dismantle control but to ensure that controls still serve the business.

By questioning the origin, purpose, and impact of each rule, analysts uncover hidden opportunities for innovation—turning bureaucracy into strategic advantage.

How can prototyping and experimentation support paradigm shifts in business analysis?

Adrian M. — Mon, 10 Nov 2025 01:10:00 GMT

Prototyping and experimentation support paradigm shifts by providing a safe, evidence-based way to test new ideas before full implementation. Rather than debating theory, analysts use quick models or pilot processes to validate new assumptions.

Key benefits:

Reduces risk: Confirms feasibility before investing in large changes.

Builds stakeholder buy-in: Seeing is believing—visual prototypes help teams grasp unfamiliar concepts.

Encourages innovation: Teams are more open to radical ideas when they can test them in a controlled environment.

For example, a BA proposing automated claims handling might pilot it for a single product line to measure turnaround time and error rates.
If the experiment succeeds, it provides evidence to support a broader paradigm shift.

Prototyping moves paradigm shifts from abstract theory to tangible, data-driven reality.

What analysis techniques can business analysts use to uncover hidden assumptions?

Adrian M. — Mon, 10 Nov 2025 01:06:00 GMT

Business analysts can uncover hidden assumptions by applying structured analysis techniques that expose the reasoning beneath surface-level explanations.

Common methods include:

Root Cause Analysis – tracing recurring problems to systemic causes

The Five Whys – repeatedly asking “why” to reveal underlying logic

Business Rules Analysis – identifying outdated policies disguised as constraints

Context Diagrams – questioning whether system boundaries are still valid

In addition, brainstorming, mind mapping, and scenario analysis can help teams articulate beliefs they didn’t realize they held. By making implicit assumptions explicit, analysts prevent new systems from being built on old thinking.

Uncovering hidden assumptions is the first step toward a true paradigm shift—the moment when a team stops tweaking existing structures and starts designing a better one.

How can visual modeling techniques help business analysts challenge existing paradigms?

Adrian M. — Mon, 10 Nov 2025 01:04:00 GMT

Visual modeling techniques help business analysts challenge existing paradigms by revealing system interactions, inefficiencies, and hidden assumptions that text descriptions often obscure.
Models make the abstract concrete—allowing stakeholders to “see” how a process really works.

Useful modeling tools include:

Process Flow Diagrams to highlight redundant steps or decision loops

Context Diagrams to clarify external boundaries and dependencies

Data Flow Diagrams to show where inputs or outputs add little value

Visuals promote collaboration and shared understanding.

A single diagram can spark the realization that an entire process is built on outdated logic or unnecessary handoffs. By shifting discussions from what we do to why we do it, modeling empowers analysts to expose limitations and propose more effective paradigms.

What are the signs that an organization is stuck in an outdated business paradigm?

Adrian M. — Mon, 10 Nov 2025 01:02:00 GMT

Signs that an organization is stuck in an outdated business paradigm can be seen in both operational patterns and cultural behaviors. These red flags indicate that the team may be optimizing within a broken framework.

Operational indicators:

Repeated workarounds or manual data transfers between systems

Layered approval steps that add time but not value

Rising complexity without measurable improvement in results

Cultural indicators:

Phrases like “we’ve always done it this way”

Reluctance to experiment or pilot new approaches

Persistent user complaints despite “fixes” or upgrades

When such symptoms persist, the analyst’s role is to name the paradigm—the outdated belief or structure at the core of the inefficiency. Once identified, the team can explore alternative models aligned with today’s business goals and customer expectations.

Why are incremental improvements sometimes insufficient to deliver business value?

Adrian M. — Mon, 10 Nov 2025 01:00:00 GMT

Incremental improvements in business analysis refine existing workflows but often fail to address flaws in the underlying system. If outdated rules, rigid systems, or flawed business models are the true culprits, polishing the process only delays deeper reform.

Consider a scenario: reducing approval time by 10% won’t help if the approval process itself no longer serves a purpose.

In such cases, analysts must shift from “how can we make this faster?” to “why are we doing this at all?”

Key insights:

Incremental change works for optimization, not transformation.

True business value often requires redefining the process itself.

Paradigm shifts—like moving from paper forms to self-service portals—enable measurable leaps in efficiency and customer satisfaction.

Recognizing when incremental improvement has reached its limit is essential for analysts who want to lead real innovation rather than maintain the status quo.

How does thinking outside the box help business analysts identify problems more effectively?

Adrian M. — Mon, 10 Nov 2025 00:58:00 GMT

Thinking outside the box in business analysis means stepping beyond traditional viewpoints to explore alternative ways a problem could be framed or solved. Analysts who adopt this mindset question whether a stated issue reflects the real root cause—or merely a symptom.

This approach helps analysts:

Examine problems from user, data, and process perspectives.

Spot constraints or “invisible rules” that others accept without question.

Reframe problems in ways that lead to creative, high-impact solutions.

For instance, instead of asking how to speed up manual data entry, a creative analyst might ask why the data is entered manually at all.
That question could open the door to process automation or system integration.

By thinking beyond boundaries, analysts uncover opportunities that traditional methods overlook.
This ability to challenge assumptions and connect patterns across domains is what turns business analysis from documentation into discovery.

What is a paradigm shift in business analysis, and why does it matter?

Adrian M. — Mon, 10 Nov 2025 00:56:00 GMT

A paradigm shift in business analysis is a fundamental change in how a problem or opportunity is understood, analyzed, or solved. Rather than improving what already exists, the analyst challenges the assumptions and constraints that define the current system.

For example, moving from manual approvals to automated business rules is not simply an efficiency improvement—it redefines how decisions are made.

This kind of shift changes the very framework of the process rather than its surface details.

Why it matters:

Incremental improvements eventually reach diminishing returns.

Business environments evolve faster than legacy processes and technologies.

A paradigm shift allows organizations to rethink outdated models and unlock exponential gains.

Recognizing when to initiate a paradigm shift is one of the hallmarks of a mature analyst—transforming limited optimizations into long-term strategic value.

What is the STRIDE technique for security analysis?

Adrian M. — Mon, 20 Oct 2025 00:31:00 GMT

STRIDE is a threat modeling framework developed by Microsoft to help identify and categorize potential security threats in software systems. It is commonly used during system design and architecture review to proactively uncover vulnerabilities before implementation or deployment.

1. Meaning of STRIDE

Each letter in STRIDE represents a type of security threat:

Letter	Threat Category	Description	Example
S	Spoofing	Impersonating another user, system, or process.	Logging in using someone else’s credentials.
T	Tampering	Modifying data or code, either in transit or at rest.	Altering a database record or configuration file.
R	Repudiation	Performing actions that cannot be traced or proven.	A user denies performing an operation because there is no audit log.
I	Information Disclosure	Exposing information to unauthorized entities.	Leaking personal data through logs or unsecured APIs.
D	Denial of Service (DoS)	Making a system or service unavailable to legitimate users.	Flooding a server with requests to crash it.
E	Elevation of Privilege	Gaining higher access rights than intended.	A normal user executes administrative commands.

2. Purpose and Benefits

STRIDE provides a structured approach for:

Identifying security risks early in the design phase.

Improving system resilience and compliance with security standards.

Facilitating communication among developers, analysts, and security teams.

It aligns with data flow diagrams (DFDs) — each DFD element (process, data store, data flow, external entity) can be analyzed against STRIDE categories to find relevant threats.

3. How STRIDE Works (Process)

Model the system: Create a Data Flow Diagram (DFD) or architecture diagram showing processes, data stores, data flows, and external entities.
Identify trust boundaries: Mark where different security privileges meet—these are high-risk areas.
Apply STRIDE categories: For each element in the DFD, ask STRIDE-based questions (e.g., “Can this data flow be tampered with?”).
Document threats: Log identified threats, their likelihood, and potential impact.
Mitigate and validate: Recommend and apply mitigations (authentication, encryption, logging, etc.), then validate the design.

4. Example

In a web application handling customer logins:

Spoofing: An attacker fakes a login token.

Tampering: JavaScript files are modified on the server.

Repudiation: No audit log of failed logins.

Information Disclosure: Passwords sent without encryption.

Denial of Service: Automated requests overwhelm the login endpoint.

Elevation of Privilege: A user manipulates a session to access admin features.

What facilitation traps do you watch for in executive workshops?

Adrian M. — Sat, 10 May 2025 01:15:00 GMT

Facilitation traps I vigilantly avoid in executive workshops—and how I steer around them are as follows:

Trap	Why It Hurts	My Counter-Move
C-Suite Soliloquy – one leader dominates the airtime	Silences dissent, skews priorities toward a single lens	Use a visible “round-robin” queue and time-box each voice; summarize points to signal closure before moving on
Solutioneering Too Soon	Jumps to pet technologies before objectives are clear	Park premature solutions on a flip-chart, label it “Ideas—Revisit,” and refocus on why not how
Status Theater – updates masquerading as strategy	Burns time on tactical minutiae	Send pre-reads for status; open the session by reaffirming the strategic question and desired outputs
Groupthink & Halo Bias	Consensus forms around the highest-paid opinion, stifling alternatives	Introduce silent brainstorming (stickies or chats), then affinity-cluster ideas anonymously before discussion
Scope Creep Live	New agenda items pile on, diluting depth	Display a visible agenda with time allocations; invoke the “parking lot” for off-topic items and promise follow-up
Decision Fog – no clear next steps	Momentum dies post-workshop	End with a RAPID-style decision log: owner, approver, input providers, deadlines

Why it matters: Executives expect high-impact use of their time. By anticipating these traps, I protect focus, ensure balanced participation, and convert dialogue into concrete, owned decisions—turning a workshop into an accelerating force rather than a calendar expense.

What are the Most Important Skills of a Business Analyst?

Adrian M. — Sun, 13 Oct 2024 01:51:00 GMT

A Business Analyst (BA) plays a pivotal role in bridging the gap between business objectives and technological solutions. They are responsible for identifying business needs, analyzing processes, and proposing strategies that deliver value. To excel in this role, a Business Analyst must possess a wide variety of skills. Below is a look at the most essential skills that define a successful Business Analyst.

1. Analytical Thinking and Problem-Solving

The ability to objectively analyze complex business challenges, identify patterns and root causes, and develop effective solutions to address them.

2. Effective Communication

The skill of clearly and concisely conveying ideas, requirements, and feedback both verbally and in writing to diverse audiences.

3. Stakeholder Management

The capability to identify, engage, and build strong relationships with stakeholders, managing their expectations and facilitating their involvement throughout the project.

4. Technical Proficiency

Having a solid understanding of IT systems, software development processes, and emerging technologies to bridge the gap between technical teams and business needs.

5. Requirements Gathering and Elicitation

The practice of effectively extracting and documenting business requirements through techniques like interviews, workshops, and observations.

6. Documentation and Modeling Skills

The ability to create clear and detailed documentation and visual models, such as flowcharts and use cases, to represent business processes and system functionalities.

7. Decision-Making and Prioritization

The skill of evaluating options, assessing risks and benefits, and prioritizing tasks and requirements based on their value and impact on the business.

8. Adaptability and Flexibility

The capacity to adjust to new information, changing environments, and shifting priorities while maintaining effectiveness and focus.

9. Attention to Detail

Ensuring accuracy and thoroughness in analyzing information and producing deliverables to prevent errors and oversights.

10. Leadership and Influence

The ability to guide and motivate teams, influence stakeholders without formal authority, and drive projects toward successful outcomes.

What is Flow?

Adrian M. — Sat, 11 Nov 2023 21:43:00 GMT

The concept of flow, as proposed by psychologist Mihaly Csikszentmihalyi, is a concept in positive psychology that describes a mental state of complete absorption, focus, and involvement in an activity. This state is characterized by a deep and effortless concentration on the present moment, a sense of control, and a loss of self-consciousness. When individuals experience flow, they often feel a high level of enjoyment and satisfaction from the activity itself.

Csikszentmihalyi, suggested that the experience of flow occurs when there is a balance between the individual's skill level and the challenge level of the activity at hand. The relationship between skill and challenge is often represented by a flow channel, as depicted in the following diagram:

Image source: Amber Case on flickr.com

Here's how the interaction between skill and challenge affects the experience of flow:

Low Skill, Low Challenge leads to Boredom -> When a task is too easy for an individual (low challenge) and their skill level is high, they may become bored. The lack of challenge can lead to disengagement and a sense of monotony.

High Skill, Low Challenge leads to Apathy -> If a task is too easy for someone with a high skill level, they may feel apathetic or uninterested. The lack of challenge fails to engage their skills fully, resulting in a sense of indifference.

Low Skill, High Challenge leads to Anxiety -> On the other hand, if a task is too difficult for an individual whose skill level is low, they may experience anxiety. The high challenge can be overwhelming, leading to frustration and stress.

High Skill, High Challenge leads to Flow -> The optimal state for experiencing flow occurs when the challenge level of the task matches the individual's skill level. In this balanced state, people are fully engaged, focused, and experience a sense of control and mastery. This is the ideal condition for flow to occur.

The key to achieving flow is to find work and activities that match or slightly exceed your individual current skill level, providing an optimal level of challenge.

Csikszentmihalyi identified flow as a key element in achieving happiness and optimal human functioning. Flow involves a high level of concentration and attention on the task at hand. The individual becomes fully immersed in the activity, and distractions fade away. Those in a state of flow feel a sense of control over their actions and the outcome of the activity. They experience a sense of mastery and competence.

Is flow relevant in business analysis? Yes. Business analysts, as any other professional, can achieve the state of flow, enabling them to be more productive, successful, and happier in their business analysis career.

What is Business Architecture?

Adrian M. — Sun, 09 Jul 2023 01:48:00 GMT

Most of us are familiar with the term architecture… The first thing that comes to mind is a specific building or structure. In this context, architecture refers to the practice of careful design and building of the various components, and their integration, that make up the given structure.

Very similarly, business architecture is the deliberate design, organization, and building of an organization designed for a given purpose.

The Object Management Group (OMG) defines Business Architecture as follows:

“The structure of the enterprise in terms of its governance structure, business processes, and business information. In defining the structure of the enterprise, business architecture considers customers, finances, and the ever-changing market to align strategic goals and objectives with decisions regarding products and services; partners and suppliers; organization; capabilities; and key initiatives.”

In other words, business architecture refers to the deliberate and organized structure of the various business components and the relationships and interactions between them.

What is the difference between business architecture and system architecture?

System architecture deals with the design and implementation of an information system in terms of the various system layers (ex: data storage layer) and the respective components (ex: databases, data feeds, data transformations, etc.). Similarly, the business architecture deals with the various business areas (ex: finance) and the respective components (ex: accounts payable, accounts receivable, payroll, etc.)

What are some examples of business architecture components?

Just as there are many ways of representing system architecture, there are many ways of model and express business architecture.

Some of the more common elements of a business architecture are:

Capabilities

Value Streams

Products or Services

Processes

Business Rules and Policies

Organization (people, departments)

Customers

Partners & Vendors

Strategy

What are the benefits of business architecture?

The definition and deliberate design of business architecture provides many benefits to an organization, including:

Alignment - Business architecture aligns business strategy with the organization's operations, ensuring that all aspects of the business are working towards common goals.

Clarity - Business architecture provides a clear and shared understanding of how the organization operates, enabling effective communication and decision-making.

Change Management - Business architecture helps organizations plan and manage change initiatives by providing the foundation upon which to build new strategies, processes, or technologies.

Optimization - Business architecture enables the organization to identify inefficiencies, redundancies, and areas for improvement within their operations..

Integration - Business architecture enables the integration of new systems, technologies, products, or services into the existing business ecosystem.

Risk Management - Business architecture helps identify and mitigate risks by understanding dependencies, vulnerabilities, and potential impacts on the organization's operations.

What is Event-driven architecture (EDA)?

Adrian M. — Mon, 12 Jun 2023 02:43:00 GMT

Event-driven architecture (EDA) is a software design pattern that focuses on an organization’s events, messages, or important happenings in the business such as a purchase order received, a customer visit, or the emergence of a threat signal. In EDA, software components or services communicate by producing and consuming events, which can be triggered by user actions, automated system events, or external integrations.

What is Design Thinking?

Adrian M. — Sun, 02 Apr 2023 22:59:00 GMT

Design thinking is an approach to problem solving and product design that is customer-focused, starting from the needs, problems, habits, and practices of the customer. For business analysts, design thinking can prove to be a valuable approach analysis and design to develop innovative solutions through practices such as:

Understanding the user needs,

Problem definition,

Ideation and prototyping,

Collaboration and stakeholder engagement.

The chief principles of design thinking include the practice of empathy, collaboration, experimentation, as well as iteration and refinement of ideas based on user-feedback. This relentless focus on the customer, design thinking enables teams to develop solutions that are not only effective, but also user-centered and human-focused.

Some key high-level points about design thinking:

Design thinking is a problem-solving approach,

Design thinking focuses on understanding the needs of the customer,

Design thinking involves empathy, problem definition, ideation, prototyping and testing,

Design thinking emphasizes collaboration and experimentation,

Design thinking is a creative process,

Design thinking requires focus on user feedback,

Design thinking enables the developing solutions that are human-focused,

Design thinking is a tool for solving complex problems.

What is an IF… THEN… ELSE statement?

Adrian M. — Mon, 12 Sep 2022 03:33:00 GMT

The IF… THEN… ELSE statement is probably the most basic logical construct used to control the flow of logic. This type of conditional statement can be found in most programming languages but it is also commonly used when expressing logic as pseudocode.

What is the Six Thinking Hats model?

Chris Adams — Sun, 13 Sep 2020 16:00:00 GMT

The Six Thinking Hats is a role-playing model presented by Edward de Bono in 1986. It serves as a team-based problem solving and brainstorming technique that can be used to explore problems and solutions and uncover ideas and options that might otherwise be overlooked by a homogeneously thinking group.

What is the PDCA method and how is its application by the Business Analyst beneficial?

Chris Adams — Fri, 06 Mar 2020 17:50:00 GMT

PDCA is a 4-step, iterative method commonly used for Business Process Improvement. PDCA stands for Plan, Do, Check, Act.

What is the AARM Framework and how is used by Business Analysts and Product Managers?

Chris Adams — Sun, 12 May 2019 17:08:00 GMT

The AARM Framework can be used to evaluate a product idea, develop a strategy, guide the success of its launch, and understand how customers move through the different stages of a customer purchase funnel. The framework is generally applied to software, applications, or service oriented products. AARM stands for Acquisition, Activation, Retention, Monetization.

What is a Sentiment Score Chart and when might a business analyst use one?

Chris Adams — Sun, 14 Oct 2018 18:46:00 GMT

Business Analysts engage in all kinds of interviews, open response surveys, ideation workshops, and other research activities that result in large amounts of qualitative information. So much qualitative information can present challenges both in terms of absorbing and understanding the information as well as representing it visually to others. It can be difficult to turn participants’ open responses into quantitative data. A sentiment score chart is a polarized histogram that communicates both the positive and negative feedback (or sentiment) of the participants transforming qualitative data into a quantitative visualization.

What is the One Metric That Matters and how can it be used to improve a product?

Chris Adams — Mon, 12 Feb 2018 18:51:00 GMT

The One Metric That Matters (OMTM) is a minimalist approach that helps achieve this goal. OMTM is a mindset and guideline more than a rule. In practice, focusing on a single metric may be too restrictive to result in actionable data but this approach can be modified in a couple of useful ways. One is to identify a single metric for each facet of a product. Another is to focus on a single metric for a day, a week, or a month and optimize performance based on that single metric over that period of time.

Describe How Convergent and Divergent Thinking Can Be Used as a Problem Solving Technique?

Chris Adams — Wed, 07 Feb 2018 17:45:00 GMT

Divergent and Convergent thinking when used together can help an analyst arrive at better and more creative solutions than he or she otherwise might have. Divergent thinking is the process of breaking a topic down and generating many ideas that branch out from the original concept while Convergent thinking is the process of focusing on a fewer set of ideas and evaluating them based on selection criteria.

Describe the difference between univariate, bivariate and multivariate analysis?

Chris Adams — Sun, 10 Dec 2017 23:08:00 GMT

Univariate analysis is the simplest form of data analysis where the data being analyzed contains only one variable. Since it's a single variable it doesn’t deal with causes or relationships. The main purpose of univariate analysis is to describe the data and find patterns that exist within it

What is Brainswarming and how does it compare to Brainstorming?

Chris Adams — Sat, 12 Mar 2016 20:37:00 GMT

Brainswarming is a problem solving technique which questions why we really need to talk in the first place.

What is a fishbone diagram or Ishikawa diagram?

Chris Adams — Sun, 13 Dec 2015 16:30:00 GMT

A fishbone diagram is a problem-analysis tool that derives it’s name from it’s shape which resembles the skeleton of a fish. Developed by Dr. Kaoru Ishikawa, a Japanese quality control statistician, the fishbone diagram is a systematic way of looking at an effect and identifying and capturing the causes that contribute and result in that particular effect. For this reason, it is sometimes referred to as a cause and effect diagram.

The fishbone diagram is useful in:

Identifying the possible root causes of a particular problem
Identifying the most likely cause of a particular problem
Identifying areas that may be good candidates for data collection/measurement and controls

To develop a fishbone diagram:

Draw a horizontal line for the spine of the fish and list the main issue/effect at the head of the fish
Draw 4-6 vertical lines extending above and below the spine of the fish. Each should start at the spine of the fish and slant away from the head of the fish. These “major bones” are used to define the categories of causes that are to be identified. These categories can be whatever you think would work best, but are typically standardized from company to company or team to team. The categories are used to provide a framework for the brainstorming and documenting of causes. Some of the common categories are listed here. The point is you can use whatever categories you team feels is best.
- Methods, Machines, Materials, Manpower, Mother Nature, Measurements (the 6 M’s, often used for the manufacturing industry)
- Place, Procedure, People, Policies (the 4 P’s, often used for the service industry)
- Surroundings, Suppliers, Systems, Skills (the 4 S’s)
Brainstorm on the causes that result in the effect that you are analyzing. For each cause identified, determine which category it falls within and draw a “minor bone” or a line from the “major bone” of the category. Document the cause on the “minor bone”.
For each cause, ask yourself why the cause occurs. Typically a cause is itself and effect of another cause. By drilling down farther and farther you can eventually arrive at the root causes of the effect you are analyzing.
Identify which causes appear under multiple categories. These are often you most likely cause of a recurring issue and deserve the most attention.

Here's a fishbone diagram example:

--
Chris Adams
LinkedIn Profile

How well can you identify patterns and relationships in requirements or business processes?

Chris Adams — Tue, 08 Apr 2014 16:55:00 GMT

The ability to identify, understand and analyze patterns and relationships is an important skill for Business Analysts. Find the pattern to identify the missing element in each sequence below, and demonstrate proficiency in this BA skill.

8723, 3872, 2387, ? (easy)
7, 5, 8, 4, 9, 3, ?, ? (easy)
2, 4, 5, 10, 12, 24, 27, ? (easy)
5, 7, 12, 19, 31, ? (easy)
1, 4, 9, 18, 35, ? (medium)
1, 2, 6, 24, 120, ? (medium)
4, 7, 15, 29, 59, 117, ? (medium)
4, 6, 12, 18, 30, 42, 60, ? (harder)

(Answers to follow in the comments section.)

--
Sandy Lambert
Business Architect
LinkedIn Profile

Describe Pareto Analysis and how is it used?

Chris Adams — Sun, 13 Nov 2011 00:11:00 GMT

Pareto Analysis refers to the application of the Pareto Principle as a decision making technique. Pareto’s Priniciple, also known as the 80/20 rule, is most often used within the context of quality control and defect resolution and suggests that a vital few factors or causes are responsible for producing the majority of the problems.

Pareto Analysis and the Pareto Principle, however, can also be applied more broadly to any number of scenarios that result in roughly an 80/20 distribution. Often people find that 20% of the overall work effort typically achieves 80% of the work product or goal.

Pareto Analysis plots the distribution of events in a standard Pareto Chart. The Pareto Chart, named after Vilfredo Pareto, consists of a bar chart and line graph. The bar chart shows the frequency of the events along the left hand side “y” axis while the event types are plotted in descending order of frequency along the “x” axis. Then, the cumulative total of the event occurrences are plotted as a line graph and overlaid on top of the bar graph with the cumulative percentage listed along the right hand side “Y” axis.

What are 2 common attribute categories sometimes used to extend the Kano Model?

Chris Adams — Sun, 07 Aug 2011 22:08:00 GMT

Kano Analysis refers to the process of analyzing a product or system requirements to determine what the perceived impact will be on customer satisfaction.

The Kano model categorizes product attributes or system requirements into 3 primary categories to determine the perceived customer satisfaction.

Unexpected Delighters
Performance Attributes
Must Have Attributes

In addition, the Kano Model is often extended by differentiating attributes into two other categories:

Indifferent Attributes: These are attributes of a product or system that the customer doesn’t really care about one way or the other.

My smart phone example: Cellular network technology (CDMA, GPRS, GSM, etc) is for most customers an indifferent attribute. Very few customers care about the type of technology used as long as it doesn’t directly impact the quality of their service.

Reverse Quality Attributes: These are attributes of a product or system that can best be described as “more isn’t always better”. You can also consider these to be the opposite of Delighters. If the feature or attribute doesn’t exist then no big deal. However, if it does exist or it’s not designed properly, then it can create dissatisfaction. An example explains these best.

My smart phone example: Too many features can be an example of a Reverse Quality Attribute of a smart phone. You can view this from a perspective of usability. If many features are added to a smart phone but it creates an overly complicated user experience due to poor user interface design, then it has resulted in a Reverse Quality experience and customer satisfaction declines.

What techniques do you use to ensure that you have identified the principle problem or requirement?

Chris Adams — Sat, 04 Apr 2009 21:40:00 GMT

Problem solving and problem resolution is a common part of a business analyst’s role. But before you spend time figuring out resolutions to the problem, you should be sure that you’re solving the right problem or that you have the true requirement.

Problem Restatement is one category of techniques that can be used to determine that the principle problem has been identified. Some problem restatement techniques are:

Problem Paraphrasing – Alter the wording of the problem statement just slightly resulting in a new problem statement which is very similar in meaning. Repeat the process until you have arrived at the principle problem.
5W + 1H (Who, What, When, Where, Why, + How) – Create multiple variations of the problem statement beginning each statement with one of the 5W + 1H keywords.
Repeatedly Ask Why – Starting with the original problem statement, ask ‘Why’ to identify a new problem statement. Continue to ask why to each new problem statement until you arrive at what is clearly the principle problem.

Give an example of how you would use the problem restatement technique of ‘Repeatedly Ask Why’.

Chris Adams — Sat, 04 Apr 2009 21:33:00 GMT

The Repeatedly Ask Why technique starts with the original problem statement and asks ‘Why’ to identify a new problem statement. The Business Analyst continues to ask why to each new problem statement until he or she arrives at what is clearly the principle problem.

This technique is so natural that all of us have used it as toddlers. Using the ‘Repeatedly Ask Why’ technique allows the Business Analyst to overcome any assumptions that may have been made when developing the original problem statement. So revert back to that 2 year old kid and ask ‘Why’.

Example:

We need a new cafeteria vendor at our company campus. – Why?
Because the quality of the food continues to get worse. – Why?
Because they keep reusing leftovers and using lower quality products. – Why?
Because they are trying to make enough money to be profitable. – Why?
Because over the last few months fewer people have been going to the cafeteria. – Why?
Because we had layoffs and there are less people on our company campus.

At this point we can identify that the principle problem is the layoffs resulting in fewer people using the cafeteria. No matter what vendor you hire, they will have troubles being profitable under these conditions. So the original problem statement stating that a new vendor is needed is incorrect.

Give an example of how you would use the problem restatement technique of ‘5W + 1H’.

Chris Adams — Sat, 04 Apr 2009 21:29:00 GMT

The ‘5W + 1H’ technique (Who, What, When, Where, Why, + How) is used to create multiple variations of the problem statement beginning each statement with one of the 5W + 1H key words.

Example:

Should we alter our current customer service procedures?
Who should alter their current customer service procedures?
What should our current customer service procedures be?
When should we change our current customer service procedures?
Why should we alter our current customer service procedures?
How can we alter our current customer service procedures?

Rewriting the statement using the ‘5W + 1H’ technique broadens the focus of the Subject Matter Experts and Business Analysts. This technique can be used at anytime, but is particularly important if the initial problem statement is close ended phrase requiring a simple yes or no answer. This often constrains the thought process of the Subject Matter Experts and Business Analysts. The resulting statements often shed new light on the problem and help the group determine the principle issue.

Give an example of how you would use the problem restatement technique of ‘Problem Paraphrasing’.

Chris Adams — Sat, 04 Apr 2009 21:23:00 GMT

Problem Paraphrasing is altering the wording of the problem statement just slightly resulting in a new problem statement which is very similar in meaning. The process is repeated until you have arrived at the principle problem.

Example:

Drivers keep cutting me off.
Drivers keep passing me and pulling in front of me.
Drivers keep changing lanes to pass me and then pulling back in front of me.
Drivers keep pulling around me.
Drivers keep pulling around me while going the speed limit.
I’m driving to slow!

A Subject Matter Expert can tell you if each new statement still reflects a valid scenario. It’s important that each statement be valid and correct. However, this technique is useful because a Subject Matter Expert may not be able to jump directly to the principle problem. The paraphrasing technique helps the group gradually arrive at the principle problem.

What is Cost Benefit Analysis (CBA)?

Chris Adams — Fri, 06 Feb 2009 05:01:00 GMT

Cost Benefit Analysis is a technique used to determine if the financial benefits of a project outweigh the associated cost of undertaking the project in the first place. For a short term project where the benefit may be an immediate one-time cash windfall this may be as simple as subtracting the total of all the project cost from the total of all of the project benefits. If the total is positive, then the project may be worth completing.

Project Duration = 2 months
Project Costs = $50,000
Immediate Project Benefits = $75,000
$75,000 - $50,000 = $25,000

However, project costs and benefits rarely result in such a simple example. Project costs and benefits often occur over time. For this reason, Cost Benefit Analysis should consider all project cost and benefits in terms of the present value (PV) of money.

To determine the present value of a future cost or benefit we discount the value of the dollars to account for time. To calculate the Present Value we use the formula PV = FV /[(1 + i)^t].

PV = Present Value
FV = Future Value
i = Discount Rate
t = time

In our example, if the $50,000 cost was incurred immediately and the $75,000 benefit was realized 3 years in the future, using a 5% discount rate would result in the following:

PV = $75,000 / [(1 + .05)^3] = $64,787.82
$64,787.82 - $50,000 = $14,787.82

The net benefit of this project is now clearly less than originally thought.

Taking this a step further, consider the example where we have multiple cashflows (costs and benefits) over time.

@ T0, Cost = -$25,000
@ T1, Cost = -$25,000, Benefit = $15,000
@T2, Benefit = $30,000
@T3, Benefit = $30,000

By subtracting the present value of future costs from the present value of future benefits, we can arrive at the Net Present Value (NPV) of the costs and benefits for each year of the project. The sum of all NPV calculations will give us the NPV of the entire project.

NPV = FVben – FVcost / [(1 + i)^t]
NPV0 = $0 - $25,000 / [(1 + .05)^0] = -$25,000
NPV1 = $15,000 - $25,000 / [(1 + .05)^1] = -$9,523.81
NPV2 = $30,000 - $0 / [(1 + .05)^2] = $27,210.88
NPV3 = $30,000 - $0 / [(1 + .05)^3] = $25,915.13

For a total of $18,602.20 in benefit.

When faced with the user requirement "I want a flag to indicate premium customers" what questions would you ask?

Guy Beauchamp — Mon, 10 Dec 2007 20:47:00 GMT

The problem with the requirement as expressed is that it is a solution to a problem that you have not been informed about so you can't analyze whether it is a good solution or not. You will have to investigate the real requirement(s) behind the presenting requirement.

1. At what point in and in which business processes would the identification happen? Who will do it?

2. What will you do when you have identified a premium customer?

3. Now I understand why you want to identify premium customers, what other requirements would also help achieve this aim?

4. Now I understand your requirements in this area, which project objectives will they help deliver? I.e. is it in scope?

What is Joint Application Development (JAD)?

Adrian M. — Sat, 10 Nov 2007 06:58:00 GMT

JAD stands for Joint Application Development. JAD is a requirements-definition and software system design methodology in which stakeholders, subject matter experts (SME), end-users, business analysts, software architects and developers attend collaborative workshops (called JAD sessions) to work out a system's details.

The JAD approach, in comparison with more traditional practices, is thought to lead to faster development times and greater client satisfaction, because the client is involved throughout the development process

The focal point of the JAD process is the series of JAD sessions that are attended by stakeholders, executives, SME’s, end-users, business analysts, software architects and developers. It is essential that the roles, responsibilities, and rules for the JAD sessions are well defined and communicated in advance to all participants.

Some typical roles found in a Joint Application Development (JAD) session include:

Facilitator – 1 (only one) - usually a Senior Business Analyst - facilitates discussions, enforces rules,

Scribe – 1 or 2 – sometimes more junior BAs – take meeting notes and clearly document all decisions,

End users – 3 to 5, attend all sessions,

Technical Experts – 1 or 2, question for clarity and give feedback on technical constraints,

Tie Breaker – Senior manager (executive) - breaks end user ties, usually doesn’t attend,

SMEs - Subject Matter Experts,

Observers – 2 or 3 - junior BAs, testers, etc. - do not speak.